Amendments to the Specification 



Please amend the specification as follows: 

On Page 15, in the first full paragraph of the page: 

By utilizing the dynamic payment card platform, the current invention advantageously 
provides active control that is not available with traditional credit cards or other purchase cards. 
In other words, the dynamic payment card purchasing of the present invention enables small, 
midsize and large companies to utilize a bank card as a primary mechanism for managing 
spending and procurement in business operations, while still maintaining active control over 
those purchases. The static approval mode of traditional purchasing cards simply does not 
support the standard purchase approval process in most businesses, where managers review 
requests and then approve these specific requests for purchase. Many companies are not willing 
to use such traditional purchasing cards for the majority of their expenditures due to the lack of 
control over the actual purchasing execution. Such companies, therefore, limit the use of 
purchase cards or avoid them altogether. Thus, significant amounts of operational expenditures 
(technology, industrial supplies, office supplies, etc, which are often fall within 15-25% of a 
company's revenue) are processed through other mechanisms, such as reimbursement or check 
request procedures. 

On Page 16, in the first full paragraph of the page: 

The systems and methods of the present invention will now be described in further detail with 
respect to FIGS. 1-4. More specifically, FIG. 1 provides an example of a purchasing 
management environment with clients linked to the purchasing management system through a 
network and with card transaction processing occurring within a dynamic payment card 
processing system. FIG. 2 provides an example process flow diagram for use of a dynamic 
payment identifier from purchase request generation to transaction execution. FIG. 3 provides 
example markets and sources from which purchase requests may be come for injection into the 
purchasing management system. And FIG. 4 provides a flow diagram including purchases made 
both utilizing and not utilizing the dynamic payment capabilities of the present invention. 
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On Page 1 7, in the first full paragraph of the page: 

The clients 104A, 104B ... 104C represent companies or entities that are utilizing the 
purchasing management system 100. Within these companies or entities, there will have be any 
of a variety of devices and systems that may be utilized, for example, personal computers, 
servers, handheld computer devices, portable computers, personal digital assistants or any other 
device or system that is desired to be utilized. It is noted that although FIG. 1 depicts a 
purchasing management system 100 that is a server-based network-accessible system, the 
dynamic approval parameters and payment card of the present invention may be utilized with 
client-based systems, server-based systems, or a combination of both. It is further noted that the 
purchasing management system 100 represents any desired grouping of devices and systems that 
work together to provide the desired purchasing management functionality. 

On Page 18, in the first full paragraph of the page: 

According to the present invention, each user may have an individual dynamic payment 
card. Preferably, the dynamic payment eard cards are similar to traditional magnetic-strip credit 
cards and purchasing cards, which have unique numbers associated with them. These unique 
numbers provide a mechanism for allowing transactions initiated with the card may to be 
identified. It is noted, however, that other dynamic payment identifiers may be utilized other 
than magnetic-strip cards with unique number identifiers. For example, unique numbers may be 
utilized, such as social security numbers. These unique numbers would then simply be 
transmitted along with the transaction information. Furthermore, biological identifiers could be 
utilized, such as fingerprints. In short, because current infrastructure is in place to process 
magnetic-strip credit card type mechanisms, these type mechanisms are currently preferred. 
However, according to the present invention, any dynamic payment identifier may be utilized 
that will allow purchase requests and associated approval parameters to be correlated with 
initiated transactions. 

On Page 19, in the paragraph that begins in the middle of the page: 

The dynamic payment card processing system 130 includes approval parameters 
database block 132 and transaction processing block 134. The approval parameters database 
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block 132 represents subsystems that store approval parameters that are sent from the dynamic 
purchase processing block 120. These approval parameters are stored with respect to each 
specific purchase request and are, therefore, dynamic with respect to initiated transactions. Thus, 
when a user initiates a transaction, vendor systems 140 communicate with the transaction 
processing block 134. If the transaction falls within the approval parameters, the transaction 
processing block 134 approves the transactions transaction and notifies the vendor systems 140 
of this approval. If the transaction dees falls outside of the approval parameters, the transaction 
processing block 134 rejects the transaction and notifies the vendor systems 140 of this rejection. 
The transaction block 134 then sends transaction details to the transaction reconciliation and 
reporting block 122. It is noted that the dynamic payment card processing system may be similar 
to existing credit card transaction systems, such as the VisaNet credit card processing network, 
which include the ability to dynamically store a set of approval parameters per approved 
purchase requests. As indicated above, traditional purchasing card processing only stores a 
single, static set of limitations for any given purchasing card. 

On Page 24, in the first full paragraph of the page: 

In block 216, the transaction is reviewed or processed by the dynamic payment 
processing system to determine if the transaction falls within the approval parameters. If the 
transaction falls outside of these parameters, flow passes to block 224 where the transaction is 
rejected. From there, decision block 226 provides a mechanism to determine if additional 
transaction attempts are to be allowed. For example, if a» a transaction amount parameter were 
exceeded, a "yes" could be determined, and flow could then pass back to block 212 where the 
user could try to initiate an appropriate transaction. As a further example, if a time limit 
parameter could have been exceeded, a "no" could be determined, and flow could then pass back 
to block 230 wherein a new purchase request would be required. 

On Page 25, in the first paragraph on the page: 

Looking back to block 216, if the transaction does fall within the approval parameters, 
flow passes to block 218 where the transaction is completed. The transaction details are 
provided back to the purchasing management system, and in block 220, the transaction is 
reconciled with the purchase order and other information provided previously from block 208. 
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Once transactions are reconciled, accounting details may be reported to clients, as indicated by 
block 222. It is noted that multiple purchase requests from multiple users may be simultaneously 
processed through the purchase request processing flow 200, so that the reporting in block 222 
can include, for example, a monthly statement of all client transaction transactions that have 
utilized the dynamic payment identifier. 

On Pages 28-29, in the paragraph that begins at the bottom of the page of Page 28: 

After the buyer role has been exercised and a particular product are service has been 
identified for purchase related to an approved purchase request, decision block 408 is used to 
determine how the transaction is processed to completion. In block 408, a decision is made 
whether the dynamic payment card is desired to be utilized. If the dynamic payment card is not 
to be utilized, flow passes to block 418 where an order is placed with the vendor, for example, 
through a printed document, facsimile transmission, phone call, on-line access, in person or 
through any other desired medium. In block 420, the product or service is delivered. In block 
422, an invoice may be directly sent by the vendor, and in somewhat in parallel, in block 428, the 
user exercises the role of receiver of the products and services, acting to very verify receipt of the 
goods or services. In block 424, the user exercises the accounting role of matching and 
correlating the various aspects of the purchase, for example, the received products and services, 
the purchase request, the approval conditions, the purchase order, and the invoice from the 
vendor. From this point, in block 426, any necessary payment may be finalized or made to the 
vendor. It is again not e d, noted that these process flow blocks are representative and are not 
intended to designate an absolute process flow. Variations may be implemented, as desired. 

On Pages 30, in the first full paragraph of the page: 

, In block 410, the approval parameters are injected into the card processing system and 
associated with the appropriate dynamic payment card. In block 412, the user of the dynamic 
payment card places an order with the supplying vendor, for example, through a printed 
document, facsimile transmission, phone call, on-line access, in person or through any other 
desired medium. The dynamic payment card is utilized in this purchase as the charging vehicle. 
In block 414, the product or service is delivered, although it is noted that this delivery may take 
occur at any place in the process flow, and does not need to occur at the time of purchase. In 
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block 416, the vendor charges the dynamic payment card. If the charge is approved after 
correlation and review of the transaction details with the appropriate set of dynamic approval 
parameters, flow proceeds along two somewhat parallel paths to blocks 432 and 430. If the 
transaction is not approved based upon the approval information associated with the dynamic 
payment card for that purchase, the process terminates in block 417 based upon the indication of 
no approval. 

On Pages 30-3 1, in the paragraph that begins at the bottom of the page of Page 30: 

If the process continues, in block 428, a user exercises the role of receiver of the 
products and services, acting to very verify receipt of the goods or services. Somewhat in 
parallel, in block 432, card reporting provides information concerning various transaction details, 
for example, the vendor name, vendor type, amount charged or other transaction details. In block 
434, the credit balance may be decremented. In block 436, a monthly statement or invoice is 
provided to the customer through reporting or business document exchange (BDX) provided 
general ledger (GL) distribution. It is noted that this monthly statement may be generated by the 
purchasing management system 100, so that a company or entity may have all of its purchases 
designated on a consolidated statement. In block 430, the user exercises the accounting role of 
matching and correlating the various aspects of the purchase, for example, the received products 
and services, the purchase request, the approval conditions, the purchase order, and the invoice 
from the vendor. From this point, any necessary payment may also be finalized or made to the 
vendor. It is again not e d, noted that these process flow blocks are representative and are not 
intended to designate an absolute process flow. Variations may be implemented, as desired. 
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